Can you keep something similar to the original example in place? Or is it too different now for some reason?

and as you note the example with the keys, maybe include the example from your PR description as well?

type Keys<T> = { [K in keyof T]: K };
type Foo<T extends unknown[]> = Keys<[string, string, ...T, string]>;  // ["0", "1", ...Keys<T>, number]

Problem is, the original transformation (as witnessed by that example) was inconsistent with regards to property keys, so not sure there's any value in keeping it.

Yeah, I was thinking of trying to update the example, not keep it.

I guess the issue you might've run into is that we don't have great notation to describe this. The closest thing being something like:

We transform

M<[A, B?, ...T, ...C[]]

into

[M<{ 0: A }>[0], M<{ 1: B }>[1]?, ...M<T>, ...M<C[]>]

which is not too terrible.

But I think having an example still has value, so if we have to go concrete, the Keys example isn't bad.

I'll add the Keys example. In general, we now process the fixed part of the tuple just like any other object. It's really just the elements in the variable part that get special processing.

Sure, will fix.

I know it's not allowed to have non-generic variable elements follow a non-generic rest, but it would be good to make sure the checker tolerates states like that

Since you bring this up here... this is killing me 😅

type A = [number, ...boolean[], ...string[]] // error
type B = [number, ...Array<boolean>, ...Array<string>] // ok

Shouldn't those really behave the same way? IIRC I have a PR laying around somewhere that makes this error go away (by matching the behavior of the latter)

Is the PR already open?

Not that it's related, but you inspired me to file something else I've put off mentioning for a while: #57034

It is probably not the intention that we want to allow that code to be honest. But I'll let Anders weigh in.

Is the PR already open?

sure thing :) #55446

and even more surprising to the user is that you can make the error go away when moving string[] to a type alias:

type Alias = string[]
type Ok2 = [...number[], ...Alias]

So this whole rule prevents only a very narrow set of scenarios.

@DanielRosenwasser Those extra examples wouldn't really check anything related to this PR since we normalize the tuple type before the instantiation logic even sees it.

@Andarist I still think the error makes sense, but we should fix the error reporting logic to be consistent between the notations. Permitting [...string[], ...number[]] with no errors will just make users think we can actually check for a sequence of strings followed by a sequence of numbers, but that's not the case.

I'd assume that people might already be relying on the fact that spreading like this might "normalize" the shape, so I thought that it is off the table as it would be considered a breaking change.

Error reporting fixed with the latest commit.

Error reporting fixed with the latest commit.

Thank you ❤️ I like that this will be more consistent now.

I found the old behavior (without the error) moderately useful. It's cool that it will still be possible - just somewhat unfortunate that to benefit from it we'll have to use an extra type wrapper (TS playground):

type A = [number, string?];
type B = [...boolean[], boolean];
// ok in 5.3, errors with the change
type C = [bigint, ...bigint[], ...B, ...A]; // [bigint, ...(string | number | bigint | boolean | undefined)[]]

type Indirect<A1 extends unknown[], A2 extends unknown[], A3 extends unknown[], A4 extends unknown[]> = [...A1, ...A2, ...A3, ...A4]
// ok in 5.3, ok with the change
type IndirectResult = Indirect<[bigint], bigint[], B, A> // [bigint, ...(string | number | bigint | boolean | undefined)[]]

An offtopic question if I may. I noticed (on several occasions already) that instantiating array/tuple mapped types eagerly~ leads to inconsistent behaviors with the object variants. The timing of instantiation is quite different and thus the availability of certain information tends to be different between them.

What are your thoughts on making this more consistent? How feasible that would even be? When it comes to objects each property stays deferred for as much as possible and I imagine that this would require deferring this instantiation per tuple element.

In general, the advantage of eager instantiation is it is simpler to implement and it allows sharing of identical instantiations. The specific reason we eagerly instantiate mapped array and tuple types is that elsewhere in the compiler we detect arrays and tuples by looking for instantiations of Array<T> and the corresponding synthetic tuple classes. We'd have to extend those cases to also handle mapped types applied to arrays and tuples.

Thank you very much for the answer. I might want to attempt unifying this at some point - it's good to know that you don't have strong objections 😉 Or at least I read that from your comment ;p I understand that this might introduce some new complexity but I think it might be inevitable (as long as the goal is to have consistent behavior). When trying to do this, I will gather the test cases backing up that it's a desired change.

I propose some extra test cases with type aliases: